구름 Commit - SRE

2023.09.20

DevOps vs SRE

• DevOps -> 운영팀 겸 개발팀. 경계 지운 직군

• 무슨일을 어떻게 하는가로 DevOps와 SRE가 나눔

• 대부분의 DevOps는 개발:운영 = 5:5

• SRE 조직 = 사람들과 계속 소통해야되는 포지션

  • 커뮤니케이션이 중요

  • 운영 업무에 관여되어야한다.

  • 이슈 분석/백 데이터 확보가 중요 업무

  • 개발 조직을 돕는 자동화 도구를 만드는 것에 기여 - 가치

  • 조력자로서의 역할

    • 다른 사업팀들은 목표가 확실

  • 기술 = 기본

    • T자형 인재 vs U자형 인재 - SRE는 U자형 인재
    • AWS, GCP, 리눅스는 기본 = 기술은 기본
    • 어떤 역할을 할 것 인지 정의 필요

  • 목표

    • 문제를 단순하게 만들어야한다.
      • 도구/대화로 단순하게 만들 수 있다.

SRE in LINE like 시어머니

• 조직마다 하는 일의 양태나 방향이 다름
• 한 문장으로 정의하기에 너무 다양하다.

Observability - 관찰 가능성 !== 모니터링

Tool

• 도구를 어떻게 활용하느냐의 차이
• 다른 차이는 없다.

Context

• 컨텍스트 스위칭
• 맥락이 없다 -> 스케일 아웃 / 서버 증설을 해야지 : 모니터링
• 맥락이 들어가야한다. -> 왜 발생했는지 찾아야 Observability
• Open Telemeteory: 서버간 연결 고리를 만들어야 맥락을 이해할 수 있고, 맥락을 이해해야 관찰 가능성이다.

Speed

• 빠르지 않으면 별로 의미가 없다.
• 느린건 self context switching 하는건 사람이 대시보드 보는 거로도 가능
• Low log 가지고 하려는 걸 버려야한다.
• Log 샘플링를 하지말고, Metrics을 만들자

Target

• 문제를 쉽게 빨리 해결하는 것
• 에러 로그 unique id로 추후 추적

Connect

Log와 Metrics 간의 상관관계 - 로그를 가지고 가공해서 Metrics를 만드는게 더 유효할 수 있다.

모든 로그 데이터를 raw로 쌓지 말고 Metrics로 말아서 보관하자. 벡터 - Raw Log들을 메트릭으로 쌓을 수 있게 해준다. 장기 보관을 얼마나 해야하는지 -> 서비스 종류에 따라 다 다르다. 버릴 건 과감하게 버려야한다. : 웬만한 건 다 필요없다.